📝 Description
Implementation of GTests.

Depending on:

• [Mapping] Implementing == and != operators #12317
• [Core] Making aplications deregistrable V3 #12306

Tasks

• Fix exit code -11 appearing on some suites
• Fix windows not executing any test
• Fix ubuntu-intel reporting exit code as valid, and tests reporting false positives.

Related

• [Iga] Testing behaviour problem #12326 (Currently Skipped)

Kernel

Kernel changes are being discussed in separate PR's (#12281, #12306). This PR enabled the de-registration of components.

Testing Mechanism

All cpp can now be run directly from bin/Release/tests/[SuiteName]. In order to tests and debug there are several new options like:

• --gtest_filter="foo": To filter tests by name. Accepts wildcards.
• --gtest_break_on_failure: To tell to stop in the first failure
• --gtest_catch_exceptions=0: To prevent from capturing exepctions and be able to hook gdb directly on the faulty instruction

Complete list can be found in the gtest documentation.

Tests als can be run through the testing scripts as usual:

• testing/run_python_tests.py
• testing/run_python_mpi_tests.py
• testing/run_cpp_tests.py
• testing/run_cpp_mpi_tests.py

Compilation Targets

Tests are now compiled in the majority of the cases with the kratos_add_gtests macro. As example:

## CableNet Testing sources
if(${KRATOS_BUILD_TESTING} MATCHES ON)
    file(GLOB_RECURSE KRATOS_CABLE_NET_APPLICATION_TESTING_SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/tests/*.cpp)
    kratos_add_gtests(TARGET KratosCableNetCore SOURCES "${KRATOS_CABLE_NET_APPLICATION_TESTING_SOURCES}" USE_CUSTOM_MAIN)
endif(${KRATOS_BUILD_TESTING} MATCHES ON)

This macro accepts several options:

• TARGET: The target name of the library you will tests. In 99% this will be Kratos[your_app_name]Core. It will create a Kratos[your_app_name]CoreTest as result.
• SOURCES: The list of the cpp files containing your tests and possible utilities needed by them. From now on we will not accept testing utilities as part of the core libraries in order to reduce the weight of the binaries.
• USE_MPI: Added this flag if you target depends on MPI (MPICore, Trilinos, MPIExtensions, etc...)
• USE_CUSTOM_MAIN: Add this flag if you have defined a custom main for your tests. In this PR this flag is enabled for most of the applications as a transition mechanism to keep the PR as small as possible. More in the transition section.

There are new several compilation targets as a result of the changes in the tests:

(lib) KratosCore            <- Main Kratos functionality
(lib) KratosApplication     <- Python Interface (Depends on KratosCore)
(lib) KratosTestingUtils    <- Auxiliar functions for testing (Depends on KratosCore)
(exe) KratosTests           <- The actual tests (Depends on  KratosTestingUtils, KratosCore)
(lib) KratosMPICore         <- Main MPI Kratos functionality
(lib) KratosMPITestingUtils <- Auxiliar functions for testing (Depends on KratosMPICore, KratosCore)
(exe) KratosMPITests        <- The actual tests (Depends on  KratosMPITestingUtils, KratosMPICore, KratosTestingUtils, KratosCore)

In general you should not bother about those unless you want to do special things with your applications.

Transition Changes

Due to some changes in the structure of how the targets are compiler, tests no longer depend on the testing sources from Kratos. Specifically a change that will be required is to change "include/testing.h" to an include of you application testing suit.

As this would imply changing all testing sources from Kratos in a single PR, most of applications have a transition solution in which a generic suit is defined in the kernel and the includes are the same. A placeholder is provided as well which will need to be changed to the final solution.

StructuralMechanics, Geomechanics, CoSimulationApplication and MappingApplication have the new mechanism in which the suite is included directly from the application. We expect to replace the rest of applications in future PR once this is merged.

🆕 Changelog

• Adding GTests to Kratos